home *** CD-ROM | disk | FTP | other *** search
- From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
- Message-ID: <4jboij$4t3@mulga.cs.mu.OZ.AU>
- X-Original-Date: 27 Mar 1996 15:58:11 GMT
- Path: in2.uu.net!bounce-back
- Date: 27 Mar 96 17:03:40 GMT
- Approved: fjh@cs.mu.oz.au
- Newsgroups: comp.std.c++
- Subject: Re: Placement delete suggestion Keywords: delete placement
- Organization: Comp Sci, University of Melbourne
- References: <4j4ec5$d41@fsgi01.fnal.gov> <9603261124.AA22276@lts.sel.alcatel.de>
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBFAgUBMVl08uEDnX0m9pzZAQFogAF9HU3Izp3V4ztevaer+tZDMaHGOrXPydGp
- kBaTDlvsWWJ4Sb9b7X1JkxzWTIS8XSMF
- =exTH
-
- James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
-
- >b91926@fsgi01.fnal.gov (David Sachs) writes:
- >
- >|> The lack of a placement delete expression form, corresponding to
- >|> the placment new form, has been a topic for serious discussion in
- >|> this group. The obvious problem with placement delete is that
- >|> any non-awkward form could be ambiguous, though examples that
- >|> would show such ambguity are probably infrequent.
- >
- >|> In view of this, it might be reasonable if the standards committee
- >|> bit the bullet and declare that such ambiguous forms should be
- >|> treated as placement deletes.
- >
- >Is the expression: delete (*pf)( p ) placement delete or not?
-
- That would be placement delete.
-
- >(The variable pf has type `T* (*)( T* )', and p type T*.)
-
- Irrelevant, as far as syntax analysis goes -- syntax analysis is not
- concerned with the types of variables.
-
- Your code is however an example of the sort of code that would
- get broken by this proposal.
-
- >If not, why not?
- >If so, how can I remove the ambiguity (by adding parentheses or
- >otherwise)?
-
- You could remove the ambiguity by writing
-
- delete ((*pf)(p));
-
- or simply
-
- delete pf(p);
-
- IMHO, David Sach's suggestion is a good one. Some of the committee
- members have tossed around this idea before, although I don't think it
- was ever formally proposed. The fact that it breaks existing code
- makes it a hard sell, and Bjarne was opposed to placement delete on the
- grounds that "at the point of deletion, the user can't be expected to
- know how the object was allocated" (D&E, section 10.5, page 214) and
- that consequently "the feature is feared to be error-prone" (ARM,
- section 5.3.4, page 66).
-
- The argument on the grounds of "protecting people against themselves" (D&E)
- doesn't really convince me, since as the ARM says, "added syntax isn't
- needed, since the problem can be solved without it". Rather than
- protecting them, you end up just forcing them to use an unintuitive
- syntax.
-
- The ARM continues: "The question is if such use is common enough to
- warrant the support of a special syntax.". I think the answer is yes,
- but at this stage I think it is probably too late to do anything
- about it. Not to worry -- it is a pretty minor syntax issue.
-
- Or is it? On second thoughts, I think the work-around suggested in the ARM
- of using a my_delete function won't work for array delete, since you
- don't know how many elements to delete. That is rather unfortunate --
- it certainly limits the usefulness of placement array new.
-
- --
- Fergus Henderson WWW: http://www.cs.mu.oz.au/~fjh
- fjh@cs.mu.oz.au PGP: finger fjh@128.250.37.3
- ---
- [ comp.std.c++ is moderated. To submit articles: try just posting with ]
- [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
- [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
- [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
- [ Comments? mailto:std-c++-request@ncar.ucar.edu ]
-